Skip to content

Fix #7392: Interpolate all wildcards in the resulttype of a closure #7396

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Oct 10, 2019

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Oct 9, 2019

Make sure we interpolate all wildcards in the prototype before making it
the result type of an anonymous function. This was done previously only for
toplevel wildcards, but not for wildcards nested in some type.

…a closure

Make sure we interpolate all wildcards in the prototype before making it
the result type of an anonymous function. This was done previously only for
toplevel wildcards, but not for wildcards nested in some type.
Approximating wildcard types loses too much information. it's better
to replace them by fresh typevars instead.
def interpolateWildcards = new TypeMap {
def apply(t: Type) = t match
case WildcardType => newTypeVar(TypeBounds.empty)
case WildcardType(bounds: TypeBounds) => newTypeVar(bounds)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could there be WildcardTypes in the bounds themselves that need to be replaced recursively ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe. Better to be on the safe side.

@@ -833,12 +833,18 @@ class Typer extends Namer
case _: WildcardType => untpd.TypeTree()
case _ => untpd.TypeTree(tp)
}
def interpolateWildcards = new TypeMap {
def apply(t: Type) = t match
case WildcardType => newTypeVar(TypeBounds.empty)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

newTypeVar will call constrained(poly, untpd.EmptyTree, ...) but we do actually have an owning tree that we could use here I think.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not actually change anything. We need an owning tree only to set the position of a TypeVarBinder tree. But in this case we throw the TypeVarBinder away anyway and just keep the type.

@odersky odersky merged commit 210bdc6 into scala:master Oct 10, 2019
@odersky odersky deleted the fix-#7392 branch October 10, 2019 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants